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Description 

[0001 ] This patent application is related to the following 
Patent Applications: EP 111 720 04 A2, entitled "AU- 
THORIZATION INFRASTRUCTURE BASED ON PUB- 
LIC KEY CRYPTOGRAPHY," US 6763459 B1 entitled 
"LIGHTWEIGHT PUBLIC KEY INFRASTRUCTURE 
EMPLOYING DISPOSABLE CERTIFICATES," JP 2001 
217829-A entitled "LIGHTWEIGHT PUBLIC KEY IN- 
FRASTRUCTURE USING CERTIFICATES WITH NO 
SIGNATURE" and WO 0152476-A2, entitled "PUBLIC 
KEY VALIDATION SERVICE," which were all filed on 
even date herewith, are all assigned to the same assign- 
ee as the present application. 

[0002] The present invention relates to verifying an en- 
tity's identity and/or capabilities on a data network, and 
more particularly, to an apparatus and method for using 
hierarchically structured digital certificates containing au- 
thorization information to verify the identity and/or capa- 
bilities of an entity on a data network. 
[0003] In everyday life, trust is granted between indi- 
viduals based on characteristics defining the relationship 
of the individuals and the identity of the individual in ques- 
tion, such as familiarity, occupation, status, and third par- 
ty voucher of the individual in question. However, trust 
between individuals communicating on a public internet 
is not typically granted in such a simple and straightfor- 
ward manner, because individuals can assume almost 
any identity in cyberspace. While the public internet offers 
flexibility and freedom, the public internet also instills high 
levels of distrust, especially when granting authority to 
an individual or when transmitting private, sensitive, or 
confidential information. 

[0004] On the public internet, a digital certificate is typ- 
ically used to verify the identity and/or capabilities of a 
subject or sender of the digital certificate presented to a 
recipient or relying party of the digital certificate. A third 
party, referred to as a certificate authority or issuer of the 
digital certificate, researches the subject/sender desiring 
certification, and issues a digital certificate to the subject/ 
sender to vouch that the subject/sender of the message 
is actually who they say they are. The certificate authority 
digitally signs the digital certificate. The subject of the 
digital certificate presents the signed digital certificate to 
the relying party who trusts the certificate authority. The 
relying party computes a cryptographic hash of contents 
of the digital certificate and uses the cryptographic hash 
together with a certificate authority's public key, which is 
readily available, to verify the digital signature. The ver- 
ification of the digital signature verifies that the digital 
certificate was issued by the certificate authority. 
[0005] Basic public key digital certificates contain a 
public key and a name associated with the sender. Ex- 
tended public key certificates typically contain additional 
fields of authorization information not found in the basic 
public key certificates. Authorization certificates omit the 
name, and bind the public key directly to authorization 
information. Attribute certificates omit the public key, and 



bind the name to authorization information. 
[0006] Currently, the leading digital certificate stand- 
ard is X.509 version 3 (X.509v3). The 7C.509v3 standard 
is an extended public key certificate standard, which can 

5 contain additional fields of authorization information not 
found in the basic public key certificates. The X.509v3 
standard supports Secure Sockets Layer 3.0 encryption 
along with other encryption schemes. Both Netscape 
Communicator 4.0 and Microsoft's Internet Explorer 4.0 

10 support X509v3 certificates. 

[0007] In X.509v3 digital certificates, each extension 
field has a criticality flag. The criticality flag is employed 
in situations where the recipient of a digital certificate is 
presented with one or more extension fields within the 

15 digital certificate that the recipient does not understand, 
perhaps because the extension field is newer than the 
computer program used by the recipient. If the criticality 
flag is not set, the recipient can ignore the unknown ex- 
tension field. If the criticality flag is set, the relying party 

20 must reject the digital certificate. 

[0008] In certain situations, it is convenient to collect 
information intended for multiple uses in the same digital 
certificate by using two or more unrelated fields within 
the digital certificate. This approach provides the simplic- 

25 jty of a single digital certificate for a wide variety of au- 
thentication and authorization needs. This approach, 
however, compromises confidentiality since all recipients 
have access to all fields, related or unrelated to the re- 
cipient's requirements. For example, a single digital cer- 

30 tificate may grant access to a Unix platform and also grant 
permission to sign purchase orders. In this example, the 
digital certificate has first type fields that specify a user 
ID and group ID for the Unix platform, as well as second 
type fields that specify a limit on the value of purchase 

35 orders that the recipient of the digital certificate is author- 
ized to sign. Thus, when the digital certificate is used to 
access the Unix platform, the second type fields (i.e., the 
purchase order limit) are unrelated to the recipient's re- 
quirements and may become visible to the Unix admin- 

40 istrator, such as by being recorded on the system log. 
The Unix administrator has no need to know the limit on 
the value of purchase orders, and it would be best if this 
purchase order information were not disclosed unneces- 
sarily. 

45 [0009] Alternative approaches have been developed 
to work around the confidentiality problem that results 
from two or more unrelated fields residing within the same 
digital certificate. In a first alternative approach, confi- 
dentiality is achieved by encrypting some or all of the 

50 fields of the digital certificate. The first alternative ap- 
proach only provides protection against a third party that 
eavesdrops on the transmission of the digital certificate 
to the relying party. This first alternative approach cannot 
provide confidentiality against the recipient itself, be- 

55 cause the recipient needs access to the plaintext of the 
entire digital certificate in order to compute a crypto- 
graphic hash necessary to validate the digital certificate. 
[0010] In a second alternative approach, the sender 
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uses separate digital certificates instead of placing infor- 
mation in multiple, unrelated fields within a single digital 
certificate. For example, instead of using one digital cer- 
tificate containing the public key and the name of the 
sender together with three types of fields containing au- 
thorization information for three unrelated applications, 
the second alternative approach uses four separate dig- 
ital certificates. The four separate digital certificates in- 
clude a first basic public key certificate binding the public 
key to the sender name, and three attribute certificates. 
Each attribute certificate binds the sender name to the 
corresponding authorization information contained in the 
field type of the given attribute certificate. This second 
alternative approach has an advantage in that the four 
digital certificates can be signed by four independent cer- 
tificate authorities. On the other hand, the second alter- 
native approach has the disadvantage in that it requires 
four digital signatures instead of one, and four transac- 
tions over a network instead of one when the certificate 
authority issues the digital certificate to the subject. Thus, 
the second approach is more computationally expensive 
and results in more network traffic than the certificate 
authority issuing a single digital certificate to the subject. 
[0011] In another approach, as discussed in SET Se- 
cure Electronic Specification Book 1 : Business Descrip- 
tion, Version 1 .0 (May 31 , 1 997), protected fields are en- 
crypted using a "dual signature" scheme, where individ- 
ual "message digests" are concatenated together, 
signed, and delivered to a verifier. The dual signature is 
computed using the user's private key whereby the re- 
cipients must trust the user. In another approach, as dis- 
cussed in J. Press, Secure Transfer of Identity and Priv- 
ilege Attributes in an Open Systems Environment, Com- 
puters & Security, 10 at 1 17-27 (1991), protected fields 
are encrypted before the digital certificate is issued, ei- 
ther with the end system's cryptographic key, or with a 
cryptographic key shared between the certificate's issuer 
and a trusted arbitrator. In this later approach the digital 
certificate must be issued with the field protections in 
place, and the field access permissions are not reconfig- 
urable after issuance of the digital certificate. 
[0012] The present invention seeks to provide an im- 
proved digital certificate. According to an aspect of the 
present invention, there is provided a system for enabling 
multiple recipients of a structural digital certificate to au- 
thorize a subject of the structured digital certificate as 
specified in claim 1 . 

[0013] According to another aspect of the present in- 
vention, there is provided a method of providing confi- 
dentiality of authorization information as specified in 
claim 3. 

[001 4] The preferred embodiments can provide an im- 
proved type of digital certificate and corresponding im- 
proved methods of employing the digital certificate so 
that when the sender of a digital certificate presents the 
digital certificate to the recipient of the digital certificate 
for a given purpose, only those fields of the digital certif- 
icate that have to be inspected by the recipient are re- 



vealed to the recipient. The preferred desired digital cer- 
tificate provides this recipient confidentiality protection 
without the added computational and network traffic over- 
head resulting from issuing digital certificates. 

5 [0015] According to the preferred embodiment, there 
is provided a structured digital certificate for enabling a 
first recipient of the structured digital certificate to author- 
ize a sender of the structured digital certificate. The struc- 
tured digital certificate includes a first type field of author- 

10 ization information relevant to the first recipient and read- 
able by the first recipient. The structured digital certificate 
includes a first cryptographic folder containing a second 
type field of authorization information relevant to a sec- 
ond recipient. The second type field of authorization in- 

15 formation is not readable by the first recipient. 

[0016] In one embodiment, the structured digital cer- 
tificate includes asecond cryptographic folder containing 
the first type field. In one embodiment, the first type field 
is not contained in a folder. In one embodiment, there 

20 are multiple first type fields in the structured digital cer- 
tificate. 

[0017] In one embodiment, the structured digital cer- 
tificate includes a sender name and a public key associ- 
ated with the sender. 

25 [0018] In one embodiment of the present invention, the 
cryptographic folders of authorization information are 
structured fields, containing a plurality of nested fields. 
Each of the plurality of nested fields can be a folder itself. 
In one embodiment, the digital certificate is an X.509v3 

30 digital certificate. The X.509v3 digital certificate may in- 
clude extension fields that describe how the certification 
can be used. The extension fields include one or more 
criticality flags. In one embodiment the unrelated crypto- 
graphic folders contain an encrypted hash value. 

35 [0019] The preferred embodiment also provides a 
method of providing confidentiality of authorization infor- 
mation in a digital certificate shared by multiple recipi- 
ents. The method provides cryptographic folders in the 
digital certificate. At least one first type cryptographic 

40 folder contains at least one first type field of authorization 
information relevant to a first recipient. At least one sec- 
ond type cryptographic folder contains at least one sec- 
ond type field of authorization information relevant to a 
second recipient. The certificate authority issues the dig- 

45 ital certificate by signing the digital certificate and sending 
the signed digital certificate to the subject. The subject 
then delivers the signed digital certificate to the first re- 
cipient. The at least one first type field of authorization 
information is readable by the first recipient. The at least 

50 one second type field of authorization information is not 
readable by the first recipient. The first recipient verifies 
the authenticity of the signed digital certificate. 
[0020] According to another aspect of the present in- 
vention, there is provided a method of signing a digital 

55 certificate at a certificate authority. The method provides 
cryptographic folders in the digital certificate having au- 
thorization information. The certificate authority closes 
all of the cryptographic folders in the digital certificate. A 
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cryptographic hash of the digital certificate is computed 
with all folders closed. Digital certificate signature is com- 
puted with the computed cryptographic hash of the digital 
certificate and a private key of the certificate authority. 
[0021] In one embodiment, a given cryptographic fold- 
er X is closed according to the present invention in the 
following manner. All of the nested folders in folder X are 
recursively closed. A cryptographic hash is computed of 
the contents of folder X including all recursively closed 
nested folders in folder X. The contents of folder X are 
replaced with the computed cryptographic hash of the 
contents of folder X. A flag is set in the header of folder 
X to indicate that folder X is closed. 
[0022] According to another aspect of the present in- 
vention, there is provided a method of delivering a digital 
certificate from a subject of the digital certificate to a re- 
cipient of the digital certificate. The method provides 
cryptographic folders in the digital certificate having au- 
thorization information. A digital certificate signature is 
transmitted from a certificate authority to the subject of 
the certificate. An unsigned copy of the digital certificate 
is transmitted from the certificate authority to the subject 
of the certificate. Any folders in the unsigned copy of the 
digital certificate that do not have authorization informa- 
tion relevant to the recipient are closed. The unsigned 
copy of the digital certificate and the digital certificate 
signature are transmitted from the subject of the digital 
certificate to the recipient. 

[0023] In one embodiment of the present invention, the 
step of transmitting a copy of the unsigned digital certif- 
icate from the certificate authority to the subject of the 
certificate is performed over a secure delivery channel. 
In one embodiment, the secure delivery channel is pro- 
tected via Internet Protocol Security (IPSEC). In another 
embodiment, the secure delivery channel is protected by 
Secure Sockets Layer (SSL). 

[0024] According to another aspect of the present in- 
vention, there is provided a method of verifying a signa- 
ture for a digital certificate sent by a subject of the digital 
certificate to a recipient of the digital certificate. The meth- 
od provides cryptographic folders in the digital certificate 
having authorization information. The recipient obtains a 
public key of the certificate authority corresponding to a 
private key used by the certificate authority to sign the 
digital certificate. The recipient closes any of the crypto- 
graphic folders left open in the digital certificate by the 
subject of the digital certificate. The recipient computes 
a cryptographic hash of the digital certificate. The recip- 
ient authenticates the signature for the digital certificate. 
[0025] The structured digital certificate and corre- 
sponding methods of employing the structural digital cer- 
tificate according to the described embodiments offer 
several advantages over conventional digital certificates. 
A single structured digital certificate according to the 
present invention can be utilized for multiple, unrelated 
purposes and still provide recipient confidentiality pro- 
tection withoutthe added computational and network traf- 
fic overhead resulting from sending multiple digital cer- 



tificates. The hierarchical structure of cryptographic fold- 
ers utilized within the present invention makes it possible 
to disclose only those fields of the structured digital cer- 
tificate that have to be inspected by the recipient for a 

5 given specific purpose. Since all but one folder of a struc- 
tured digital certificate will typically be closed (i.e., con- 
tents of the folder replaced with a cryptographic hash), 
when the digital certificate is transmitted from the sender 
to the recipient over a network, the time taken to transmit 

10 the digital certificate over the network is reduced. 

[0026] An embodiment of the present invention is de- 
scribed below, by way of example only, with reference 
to the accompanying drawings, in which: 

15 Figure 1 is a block diagram of an embodiment of 
structured digital certificate; 

Figure 2 is a flowchart illustrating an embodiment of 
method of providing field confidentiality in digital cer- 
tificates; 

20 Figure 3A is a flowchart illustrating an embodiment 

of method of signing structured digital certificates at 
a certificate authority; 

Figure 3B is a flow chart illustrating an embodiment 
of method of closing a given cryptographic folder X; 

25 Figure 4 is a block and data flow diagram illustrating 
how a signature is generated for a structured digital 
certificate at a certificate authority; 
Figure 5 is a flowchart illustrating an embodiment of 
method of delivering a structured digital certificate 

30 and corresponding encrypted message to a mes- 
sage recipient; 

Figure 6 is a block and dataflow diagram illustrating 
how a structured digital certificate is delivered to a 
message recipient from a certificate authority, via 

35 the subject of the certificate; 

Figure 7 is a flowchart illustrating an embodiment of 
method of verifying the authenticity of a signature of 
a structured digital certificate; 
Figure 8 is a block and data flow diagram illustrating 

40 how an embodiment of message recipient verifies 
the authenticity of a structured digital certificate; and 
Figure 9 is a block diagram of a computer system 
and a corresponding computer readable medium in- 
corporating a function for providing field confidenti- 

45 ality in digital certificates. 

[0027] In the following detailed description of the pre- 
ferred embodiments, reference is made to the accompa- 
nying drawings which form a part hereof, and in which is 

50 shown by way of illustration specific embodiments in 
which the invention may be practiced. It is to be under- 
stood that other embodiments may be utilized and struc- 
tural or logical changes may be made without departing 
from the scope of the claims. The following detailed de- 

55 scription, therefore, it not to be taken in a limiting sense. 
[0028] Figure 1 is a block diagram of an embodiment 
of structured digital certificate 30. Structured digital cer- 
tificate 30 is a data structure, digitally signed by an issuer 
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(i.e., a certificate authority), that includes authorization 
information about another entity, referred to as a subject 
(i.e., asender). The subject of structured digital certificate 
30 presents the structured digital certificate to third par- 
ties who trust the issuer of structured digital certificate 
30. The third parties are referred to as relying parties 
(i.e., recipients). The relying party computes a crypto- 
graphic hash of the structured digital certificate 30 and 
uses this hash, together with the public key of the issuer, 
which is readily available, to verify the digital signature 
of structured digital certificate 30. 
[0029] In one embodiment, structured digital certificate 
30 is a basic public key certificate and includes a public 
key 32 and a sender name 34 associated with the subject 
of structured digital certificate 30. In another embodi- 
ment, structured digital certificate 30 is an extended pub- 
lic key certificate and includes, in addition to public key 
32 and sender name 34, additional fields 36, 37 and/or 
cryptographic folders 38, 40, 42 and 44 which contain 
authorization information. One example of an extended 
public key certificate is a X.509v3 certificate, previously 
described in the Background of the Invention section of 
the present specification. 

[0030] In one embodiment, structured digital certificate 
30 includes authorization fields 36 and 37 containing au- 
thorization information used for multiple, unrelated pur- 
poses. When structured digital certificate 30 is used for 
one specific purpose, it is desirable to hide the informa- 
tion contained in unrelated fields. One example struc- 
tured digital certificate 30 can be used to grant access 
to a UNIX platform and to also grant permission to sign 
purchase orders. As a result, example structured digital 
certificate 30 has a first type authorization field 37 that 
specifies a user ID and a group ID for the UNIX platform, 
as well as a second type authorization field 36 that spec- 
ifies a limit on the value of the purchase orders that the 
subject is authorized to sign. When example structured 
digital certificate 30 is used to access the UNIX platform, 
all authorization fields 36 and 37 of structured digital cer- 
tificate 30 may become visible to the UNIX administrator, 
such as by being recorded on the system log. However, 
the UNIX administrator has no need to know the limit on 
the value of purchase orders as contained in second type 
authentication field 36. Thus, it is desirable to hide the 
information contained in second type authentication field 
36 when the UNIX administrator examines structured dig- 
ital certificate 30. 

[0031] In one embodiment, an authorization field (or 
fields) is kept confidential by placing the authorization 
field in one of the cryptographic folders 38, 40, 42, and 
44 and replacing the authorization information of the 
cryptographic folder with a cryptographic hash of the au- 
thorization information. This is accomplished without im- 
pairing the ability of the recipient of structured digital cer- 
tificate 30 to verify the digital signature. 
[0032] Cryptographic folders 38, 40, 42 and 44 are 
each a structured field, containing any number of nested 
fields. The nested fields can themselves be cryptographic 



folders. In the illustrated example, structured digital cer- 
tificate 30 contains four cryptographic folders 38, 40, 42, 
and 44. Cryptographic folder 42 contains two additional 
cryptographic folders 46 and 48 along with authorization 
5 field 50. Cryptographic folder 48 contains one additional 
cryptographic folder 52 along with authorization field 54. 
[0033] In one embodiment, cryptographic folders 38, 
40, 42, 44, 46, 48, and 52 can be in one of two states, 
open or closed. The current state is indicated by a flag 
10 in the header of the cryptographic folder. In X.509v3 dig- 
ital certificates, each extension (i.e., authorization) field 
has a criticality flag. The criticality flag is employed in 
situations where a recipient (i.e. , relying party) is present- 
ed with one or more extension fields that it does not un- 
15 derstand, perhaps because the extension is newer than 
the computer program used by the relying party. If the 
criticality flag is not set, the relying party can ignore the 
unknown extension. If the criticality flag is set, the relying 
party rejects structured digital certificate 30. 
20 [0034] Cryptographic folders provide for increased 
flexibility in the use of criticality flags, but the interaction 
of cryptographic folders and criticality flags must be han- 
dled cautiously. An authorization field is defined recur- 
sively as being visible if it is not inside a cryptographic 
25 folder or if it is inside an open cryptographic folder which 
is itself visible. An application must reject a digital certif- 
icate if it contains a visible field where the criticality flag 
is set. 

[0035] The issuer of the structure digital certificate 30 
30 must ensure that a critical field is not placed inside an 
irrelevant cryptographic folder. Thus, if a critical field is 
relevant to a relying party, then, in the folder hierarchy, 
every cryptographic folder containing the authorization 
field must also be relevant to that relying party. These 
35 cryptographic folders must be open when the structured 
digital certificate 30 is presented to the relying party, and 
the critical authentication field must be visible. 
[0036] FIG. 2 is a flowchart of a method illustrated gen- 
erally at 1 00 for providing field confidentiality in structured 
40 digital certificates, such as the structured digital certifi- 
cate 30 illustrated in FIG. 1. At block 102, method 100 
begins by signing structured digital certificate 30 at a cer- 
tificate authority. The certificate authority (i.e., issuer) of 
structured digital certificate 30 closes all cryptographic 
45 folders within the structured digital certificate in order to 
generate a signature for the structured digital certificate. 
The method step indicated at block 102 for signing the 
structured digital certificate 30 is described in greater de- 
tail in reference to FIG. 3A. 
50 [0037] After structured digital certificate 30 has been 
signed at block 102, the digital certificate signature and 
a copy of the digital certificate with at least one crypto- 
graphic open folder is delivered to the recipient via the 
subject of the digital certificate, as indicated at block 1 04. 
55 Only authorization information relevant to the recipient 
is visible to the recipient within the signed digital certifi- 
cate (i.e., via open folders). The method step indicated 
at block 1 04 for delivering the structured digital certificate 
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30 to the recipient is described in greater detail in refer- 
ence to FIG. 5. 

[0038] Upon receipt of the signed structured digital cer- 
tificate 30, the recipient verifies the authenticity of the 
signed digital certificate, as indicated at block 1 06. Before 
verifying the signed digital certificate, the recipient closes 
any cryptographic folders that are left open by the subject 
of the digital certificate. Thus, the relying party is able to 
perform the signature verification independently of the 
state of the cryptographic folders in the copy of the struc- 
tured digital certificate presented by the subject. The 
method step indicated at block 1 06 for verifying the au- 
thenticity of the structured digital certificate 30 is de- 
scribed in greater detail in reference to FIG. 7. 
[0039] FIG. 3A is a flowchart illustrating one embodi- 
ment of a method 102 for signing structured digital cer- 
tificates 30 at a certificate authority. As stated previously, 
before structured digital certificate 30 is signed or veri- 
fied, any cryptographic folders present within structured 
digital certificate 30 are closed. Method 102 begins by 
closi ng al I of the cryptog raph ic folders i n structu red dig ital 
certificate 30, as indicated at block 1 10. Next, a crypto- 
graphic hash of the structured digital certificate 30 is com- 
puted, as indicated at block 1 1 2. The cryptographic hash 
can be computed by a variety of methods. In one em- 
bodiment, the cryptographic hash is computed by SHA- 
1. At block 114, the digital certificate signature is com- 
puted with the computed cryptographic hash of the digital 
certificate and a private key of the certificate authority. 
[0040] Fig. 3B is a flow chart illustrating one embodi- 
ment of a method 1 1 5 for closing a cryptographic folder 
X. As indicted at block 116, all of the nested folders in 
folder X are recursively closed. As indicated at block 1 1 7, 
a cryptographic hash is computed of the contents of folder 
X including all recursively closed nested folders in folder 
X. As indicated at block 1 1 8, the contents of folder X are 
replaced with the computed cryptographic hash of the 
contents of folder X. As indicated at block 1 1 9, a flag is 
set in the header of folder X to indicate that folder X is 
closed. 

[0041] FIG. 4 is a block and data flow diagram illus- 
trating an operation 1 18, where a signature is generated 
for structured digital certificate 30 at the certificate au- 
thority. As indicated at block 1 10 of FIG. 3A, all crypto- 
graphic folders within structured digital certificate 30 must 
be closed before a signature can be generated. In oper- 
ation 1 1 8, the authorization information contents of open 
cryptographic folder52 (i.e., the lowest level cryptograph- 
ic folder within the hierarchy of cryptographic folders) is 
replaced with a cryptographic hash value, and crypto- 
graphic folder 52 is closed, as indicated at 1 20 in FIG. 4. 
Next, the authorization information contents of open cryp- 
tographic folders 46 and 48 are replaced with corre- 
sponding cryptographic hash values, and cryptographic 
folders 46 and 48 are closed, as indicated at 122. The 
authorization information contents of open top-level cryp- 
tographic folders 38, 40, 42, and 44 within structured dig- 
ital certificate 30 are then replaced with corresponding 



cryptographic hash values, and cryptographic folders 38, 
40, 42 and 44 are closed, as indicated at 124. At this 
point, the hierarchy of cryptographic folders within struc- 
tured digital certificate 30 have been "flattened" such that 

5 a signature can be generated for the structured digital 
certificate 30, as indicated at 126. 
[0042] FIG. 5 is a flowchart illustrating one embodi- 
ment of a method 104 for delivering structured digital 
certificate 30 to a recipient of the digital certificate. Meth- 

10 od 104 begins by transmitting the digital certificate sig- 
nature from the certificate authority (i.e., issuer) to the 
subject of the digital certificate, as indicated at block 1 30. 
At block 132, a copy of the unsigned digital certificate is 
transmitted from the certificate authority to the subject of 

15 the digital certificate. The subject of the digital certificate 
then closes any cryptographic folders in the copy of the 
unsigned digital certificate that the recipient does not 
need to see (i.e., folders do not contain authorization in- 
formation relevanttothe message recipient), as indicated 

20 at block 1 34. Finally the copy of the unsigned digital cer- 
tificate and the digital certificate signature generated by 
the certificate authority are transmitted from the subject 
of the digital certificate to the recipient of the digital cer- 
tificate, as indicated at block 136. 

25 [0043] FIG. 6 is a block and data flow diagram illus- 
trating an operation 1 50 where a structured digital certif- 
icate signed by a certificate authority is delivered to a 
recipient, via the subject of the certificate. As described 
previously, certificate authority 1 52 closes all of the cryp- 
to tographic folders within structured digital certificate 30 
before signing structured digital certificate 30. After the 
structured digital certificate has been signed, digital cer- 
tificate signature126 is delivered to a subject 154 of the 
digital certificate. In addition to the digital certificate 

35 signature126, certificate authority 152 also delivers a 
copy of the structured digital certificate 158 where all of 
the cryptographic folders are open to the subject 154 of 
the digital certificate. If the copy of the structured digital 
certificate 158 contains sensitive information, then it be- 

40 comes necessary to provide security to a delivery chan- 
nel 159 between certificate authority 152 and the subject 
1 54 of the certificate. In one embodiment, delivery chan- 
nel 159 is secured by Internet Protocol Security (IPSEC). 
In an alternate embodiment, delivery channel 159 is se- 

45 cured by Secure Sockets Layer (SSL). 

[0044] Subject 154 of the digital certificate forwards 
the digital certificate signature 126 to recipient 156. Be- 
fore submitting the copy of the structured digital certifi- 
cate 158 to recipient 156, subject 154 of the digital cer- 

50 tificate closes any cryptographic folders that recipient 1 56 
does not need to see, as indicated at 1 60. 
[0045] FIG. 7 is a flowchart illustrating one embodi- 
ment of a method 106 for verifying the authenticity of a 
signature of a structured digital certificate 30. In method 

55 1 06, recipient 1 56 obtains a public key of the certificate 
authority 1 52 corresponding to a private key used by the 
certificate authority to sign the digital certificate, which is 
made readily available by certificate authority 152, as 
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indicated at block 178. Method 106 closes any crypto- 
graphic folders left open in the copy of the structured 
digital certificate by subject 154 of the digital certificate, 
as indicated at block 1 80. As indicated at block 1 82, re- 
cipient 156 computes a cryptographic hash of the struc- 
tured digital certificate 158 with all folders closed. As in- 
dicated at block 1 84, recipient 1 56 verifies the signature 
for the digital certificate with the public key and the com- 
puted cryptographic hash of the digital certificate. 
[0046] FIG. 8 is a block and data flow diagram illus- 
trating an operation 21 0 where a message recipient ver- 
ifies the authenticity of a structured digital certificate. In 
operation 21 0, recipient 1 56 obtains a public key 214 of 
the certificate authority 152, as indicated at 178. Before 
verifying signed digital certificate 1 26, recipient 1 56 clos- 
es all cryptographic folders that were left open by the 
subject 1 54 of the certificate 1 54 in the copy of the digital 
certificate 1 60, as indicated at block 180. As indicated at 
block 1 82, recipient 1 56 computes a cryptographic hash 
21 6 of the digital certificate 212 having all cryptographic 
folders closed. As indicated at block 184, recipient 156 
verifies the signature of the digital certificate 1 26 with the 
public key 21 4 and the computed cryptographic hash 216 
of the digital certificate. 

[0047] FIG. 9 illustrates one embodiment of a compu- 
ter system 250 and an external computer readable me- 
dium 252 which can be employed to provide field confi- 
dentiality in digital certificates at a certificate authority to 
incorporate a method of signing a digital certificate; at a 
subject of the digital certificate to incorporate a method 
of delivering the digital certificate from the subject to a 
recipient of the digital certificate; or at the recipient of the 
digital certificate to incorporate a method of verifying a 
signature for the digital certificate. Embodiments of ex- 
ternal computer readable medium 252 include, but are 
not limited to: a CD-ROM, a floppy disk, and a disk car- 
tridge. Any one of the above methods for providing field 
confidentiality in digital certificates can be implemented 
in a variety of compiled and interpreted computer lan- 
guages. External computer readable medium 252 stores 
source code, object code, executable code, shell scripts 
and/or dynamic link libraries for any one of the above 
methods for providing field confidentiality in digital certif- 
icates. An input device 254 reads external computer 
readable medium 252 and provides this data to computer 
system 250. Embodiments of input device 254 include 
but are not limited to: a CD-ROM reader, a floppy disk 
drive, and a data cartridge reader. 
[0048] Computer system 250 includes a central 
processing unit 256 for executing any one of the above 
methods for providing field confidentiality in digital certif- 
icates. Computer system 250 also includes local disk 
storage 262 for locally storing any one of the above meth- 
ods for providing field confidentiality in digital certificates 
before, during and after execution. Any one of the above 
methods for providing field confidentiality in digital certif- 
icates also utilizes memory 260 within the computer sys- 
tem during execution. Upon execution of any one of the 



above methods for providing field confidentiality in digital 
certificates, output data is produced and directed to an 
output device 258. Embodiments of output device 258 
include, but are not limited to: a computer display device, 

5 a printer, and/or a disk storage device. 

[0049] A method is provided by which the subject (i.e., 
sender) of a digital certificate can keep certain fields with- 
in the digital certificate confidential as the sender 
presents the digital certificate to a relying party (i.e., re- 

10 cipient). This specific field confidentiality is accomplished 
through a structured digital certificate which includes a 
hierarchical structure of cryptographic folders. In addition 
to providing field confidentiality, the described embodi- 
ments can improve the speed of signature verification by 

15 the receiving party, reduce network traffic, and reduce 
computational overhead. 



Claims 

20 

1 . A system for enabling multiple recipients of a struc- 
tured digital certificate to authorize a subject of the 
structured digital certificate, comprising : 

25 a structure digital certificate (30) having a first 

type field of authorization Information (37) rele- 
vant to a first recipient, a second type field of 
authorization information (50) relevant to a sec- 
ond recipient, a first cryptographic folder (42) 

30 containing the second type field of authorization 

information (50), and a second cryptographic 
folder. (38-44) containing the first type field of 
authorization information, the first and second 
type fields of authorization information each be- 

35 ing readable when said respective cryptograph- 

ic folder containing said respective field of infor- 
mation is in an open state but not readable when 
said respective cryptographic folder is in a 
closed state; means for closing a cryptographic 

40 folder comprising means for replacing its con- 

tents with the computed cryptographic hash of 
its contents; and 

charactedsed in that it comprises 
a digital signature of a third party certificate au- 
45 thority issuing the structured digital certificate, 

wherein the digital signature certifies the digital 
certificate irrespective of the state of the first and 
second cryptographic folders. 

50 2. A system as claimed in claim 1, wherein the digital 
certificate further comprises one or more of, 

a plurality of nested fields and/or folders within 
one or both of the first and second cryptographic 
55 folders (46-54): 

a subject name; and/or; 

a public key associated with the subject 
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3. A method of providing confidentiality of authorization 
information in a digital certificate (30) shared by mul- 
tiple recipients, the method comprising the steps of: 

providing a digital certificate Including at least 5 
one first type field of authorization information 
(36) relevant to a first recipient and at least one 
second type field of authorization information 
(38-54) relevant to a second recipient; 
providing a first cryptographic folder (42) in the 10 
digital certificate, wherein the first cryptographic 
folder contains the at least one second type field 
of authorization information (48-54) relevant to 
the second recipient, the at least one second 
type field being readable when said first crypto- 15 
graphic folder is in an open state, but not read- 
able when said first cryptographic folder Is In a 
closed state; 

providing a second cryptographic folder (38-44) 
In the digital certificate, wherein the second 20 
cryptographic folder contains the at least one 
first type field of authorization information (36) 
relevant to the first recipient the at least one first 
type field being readable when said second 
cryptographic folder is in an open state, but not 25 
readable when said second cryptographic folder 
is in a closed state : issuing the digital certificate 
at a third party certificate autority, generating a 
digital signature based on a computed crypto- 
graphic path of the signal certificate : sending 30 
the digital signature and the digital certificate 
with the first and second cryptographic folders 
open to a subject; 

closing the first cryptographic folder at the sub- 
ject thereby preventing read access to the at 35 
least one second type field of the digital certifi- 
cate; 

delivering, from the subject to the first recipient, 
the digital signature and the digital certificate 
having the closed first cryptographic folder, 40 
wherein the at least one first type field of author- 
ization information (37) is readable by the first 
recipient, and the at least one second type field 
of authorization information (36) is not readable 
by the first recipient; 45 
verifying the authenticity of the digital certificate 
(30) by the first recipient ; and wherein the step 
of closing a cryptographic folder X comprises 
the step of replacing the contents of folder X with 
the computed syptographic hash of the contents 50 
of folder X. 

4. A method according to claim 3 or 4, wherein the step 
of verifying the authenticity of the digital certificate 
includes obtaining a public key from the third party 55 
certificate authority, closing any open cryptographic 
folders in the received digital certificate, computing 

a cryptographic hash of the received digital certifi- 



cate with all folders closed, and verifying the digital 
signature of the digital certificate with the public key 
and the computed cryptographic hash of the receded 
digital certificate. 

5. A method of signing the digital certificate of claim 1 , 
or 2, comprising the steps of: 

closing all of the cryptographic folders In the dig- 
ital certificate: computing a cryptographic hash 
of the digital certificate; and computing a digital 
signature with the computed cryptographic hash 
of the digital certificate and a private key of the 
third party certificate authority. 

6. A method of delivering the digital certificate of claim 
1 or 2. from a subject of the digital certificate to a 
recipient of the digital certificate, the method com- 
prising the steps of : 

transmitting a digital signature from the third par- 
ty certificate authority to the subject of the cer- 
tificate; 

transmitting the digital certificate having all cryp- 
tographic folders open from the certificate au- 
thority to the subject of the certificate; 
closing one or more cryptographic folders of the 
digital certificate that do not have authorization 
Information relevant to the recipient; and 
transmitting the digital certificate having one or 
more closed cryptographic folders and the dig- 
ital signature from the subject of the digital cer- 
tificate to the recipient. 

7. A method of verifying a digital signature for the digital 
certificate of claim 1 , or 2, sent to a recipient of the 
digital certificate, the method comprising the steps 
of: 

obtaining a public key of the third party certificate 
authority corresponding to a private key used by 
the certificate authority to generate the digital 
signature, 

closing any open cryptographic folders In the 
digital certificate (30); 

computing a cryptographic hash of the digital 
certificate with all the cryptographic folders 
closed; and 

verifying the digital signature for the digital cer- 
tificate with the public key and the computed 
cryptographic hash of the digital certificate. 

8. The method of any of claims 3 to 7, wherein the step 
of closing a cryptographic folder, X, composes: 

recursively closing all nested folders in folder X; 
computing the cryptographic hash of the con- 
tents of folder X; 
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replacing the contents of folder X with the com- 3. Ein Verfahren zum Bereitstellen einer Vertraulichkeit 

puted cryptographic hash of the contents of fold- von Autorisierungsinformationen in einem digitalen 

er X; and Zertifikat (30), das von mehreren Empfangern ge- 

indicating In the digital certificate that folder X is meinsam verwendet wird, wobei das Verfahren fol- 

closed. 5 gende Schritte umfasst: 



Patentanspruche 

1. Ein System zum Befahigen mehrerer Empfanger ei- 10 
nes strukturierten digitalen Zertifikats, ein Subjekt 
des digitalen Zertifikats zu autorisieren, wobei das 
System folgende Merkmale aufweist: 

ein strukturiertes digitales Zertifikat (30), das ein 15 
Feld, eines ersten Typs, von Autorisierungsin- 
formationen (37), die fur einen ersten Empfan- 
ger relevant sind, ein Feld, eines zweiten Typs, 
von Autorisierungsinformationen (50), die fur ei- 
nen zweiten Empfanger relevant sind, einen er- 20 
sten kryptographischen Ordner (42), der das 
Feld, des zweiten Typs, von Autorisierungsin- 
formationen (50) enthalt, und einen zweiten 
kryptographischen Ordner (38 - 44), der das 
Feld, des ersten Typs, von Autorisierungsinfor- 25 
mationen enthalt, aufweist, wobei die Felder, 
des ersten und des zweiten Typs, von Autorisie- 
rungsinformationen jeweils lesbar sind, wenn 
sich der jeweilige kryptographische Ordner, der 
das jeweilige Feld von Informationen enthalt, in 30 
einem offenen Zustand befindet, jedoch nicht 
lesbar sind, wenn sich der jeweilige kryptogra- 
phische Ordner in einem geschlossenen Zu- 
stand befindet; 

eine Einrichtung zum SchlieBen eines krypto- 35 
graphischen Ordners, die eine Einrichtung zum 
Ersetzen seines Inhalts durch den berechneten 
kryptographischen Hash seines Inhalts um- 
fasst; und 

40 

dadurch gekennzeichnet, dass es eine digitale Si- 
gnatur einer Drittpartei-Zertifikat-Befugnisstelle auf- 
weist, die das strukturierte digitale Zertifikat aus- 
stellt, wobei die digitale Signatur das digitale Zertifi- 
kat ungeachtet des Zustands des ersten und des 45 
zweiten kryptographischen Ordners zertifiziert. 

2. Ein System gemaB Anspruch 1 , bei dem das digitale 
Zertifikat ferner eines bzw. einen oder mehrere der 
folgenden umfasst: 50 

eine Mehrzahl verschachtelter Felder und/oder 
Ordner in einem oder beiden des ersten oder 
zweiten kryptographischen ordner3 (46 - 54); 
einen Subjektnamen; und/oder 55 
einen dem Subjekt zugeordneten offentlichen 
Schlussel. 



Bereitstellen eines digitalen Zertifikats, das zu- 
mindest ein Feld, eines ersten Typs, von Auto- 
risierungsinformationen (36), die fur einen er- 
sten Empfanger relevant sind, und zumindest 
ein Feld, eines zweiten Typs, von Autorisie- 
rungsinformationen (38 - 54), die fur einen zwei- 
ten Empfanger relevant sind, umfasst; 
Bereitstellen eines ersten kryptographischen 
Ordners (42) in dem digitalen Zertifikat, wobei 
der erste kryptographische Ordner das zumin- 
dest eine Feld, des zweiten Typs, von Autorisie- 
rungsinformationen (46 -54), die fur den zweiten 
Empfanger relevant sind, enthalt, wobei das zu- 
mindest eine Feld des zweiten Typs lesbar ist, 
wenn sich der erste kryptographische Ordner in 
einem offenen Zustand befindet, jedoch nicht 
lesbar ist, wenn sich der erste kryptographische 
Ordner in einem geschlossenen Zustand befin- 
det; 

Bereitstellen eines zweiten kryptographischen 
Ordners (38 - 44) in dem digitalen Zertifikat, wo- 
bei der zweite kryptographische Ordner das zu- 
mindest eine Feld, des ersten Typs, von Auto- 
risierungsinformationen (36), die fur den ersten 
Empfanger relevant sind, enthalt, wobei das zu- 
mindest eine Feld des ersten Typs lesbar ist, 
wenn sich der zweite kryptographische Ordner 
in einem offenen Zustand befindet, jedoch nicht 
lesbar ist, wenn sich der zweite kryptographi- 
sche Ordner in einem geschlossenen Zustand 
befindet; 

Erstellen des digitalen Zertifikats bei einer Dritt- 

partei-Zertifikat-Befugnisstelle; 

Erzeugen einer digitalen Signatur auf der Basis 

eines berechneten kryptographischen Hash des 

digitalen Zertifikats; 

Senden der digitalen Signatur und des digitalen 
Zertifikats an ein Subjekt, wobei der erste und 
der zweite kryptographische Ordner offen sind; 
SchlieBen des ersten kryptographischen Ord- 
ners bei dem Subjekt, wodurch ein Lesezugriff 
auf das zumindest eine Feld, des zweiten Typs, 
des digitalen Zertifikats verhindert wird; 
Liefern der digitalen Signatur und des digitalen 
Zertifikats, das den geschlossenen ersten kryp- 
tographische Ordner aufweist, von dem Subjekt 
an den ersten Empfanger, wobei das zumindest 
eine Feld, des ersten Typs, von Autorisierungs- 
informationen (37) fur den ersten Empfanger 
lesbar ist und das zumindest eine Feld, des 
zweiten Typs, von Autorisierungsitlformationen 
(36) fur den ersten Empfanger nicht lesbar ist; 
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Verifizieren der Authentizitat des digitalen Zer- 
tifikats (30) durch den ersten Empfanger; und 
wobei der Schritt des SchlieGens eines krypto- 
graphischen Ordners X den Schritt des Erset- 
zens des Inhalts des Ordners X durch den be- 5 
rechneten kryptographischen Hash des Inhalts 
des Ordners X umfasst. 

4. Ein Verfahren gemaG Anspruch 3, bei dem der 
Schritt des Verifizierens der Authentizitat des digita- 10 
len Zertifikats ein Erhalten eines offentlichen Schlijs- 
sels von der Drittpartei-Zertifikat-Befugnisstelle, ein 
SchlieGen jeglicher offener kryptographischer Ord- 

ner in dem empfangenen digitalen Zertifikat, ein Be- 
rechnen eines kryptographischen Hashs des emp- 15 
fangenen digitalen Zertifikats, wobei alle Ordner ge- 
schlossen sind, und ein Verifizieren der digitalen Si- 
gnatur des digitalen Zertifikats mit dem offentlichen 
Schlussel und dem berechneten kryptographischen 
Hash des empfangenen digitalen Zertifikats urn- 20 
fasst. 

5. Ein Verfahren zum Signieren des digitalen Zertifikats 
gemaG Anspruch 1 oder2, dasfolgende Schritte um- 
fasst: 25 

SchlieGen aller kryptographischen Ordner in 
dem digitalen Zertifikat; 

Berechnen eines kryptographischen Hash des 
digitalen Zertifikats; und 30 
Berechnen einer digitalen Signatur mit dem be- 
rechneten kryptographischen Hash des digita- 
len Zertifikats und einem privaten Schlussel der 
Drittpartei-Zertifikat-Befugnisstelle. 

35 

6. Ein Verfahren zum Liefern des digitalen Zertifikats 
gemaG Anspruch 1 oder 2 von einem Subjekt des 
digitalen Zertifikats an einen Empfanger des digita- 
len Zertifikats, wobei das Verfahren folgende Schrit- 
te umfasst: 40 

Senden einer digitalen Signatur von der Dritt- 
partei-Zertifikat-Befugnisstelle an das Subjekt 
des Zertifikats; 

Senden des digitalen Zertifikats, bei dem alle 45 
kryptographischen Ordner offen sind, von der 
Zertifikat-Befugnisstelle an das Subjekt des Zer- 
tifikats; 

SchlieGen eines oder mehrerer kryptographi- 
scher Ordner des digitalen Zertifikats, die keine 50 
fur den Empfanger relevanten Autorisierungsin- 
formationen aufweisen; und 
Senden des digitalen Zertifikats, das einen oder 
mehrere geschlossene kryptographische Ord- 
ner und die digitale Signatur aufweist, von dem 55 
Subjekt des digitalen Zertifikats an den Empfan- 
ger. 



7. Ein Verfahren zum Verifizieren einer digitalen Signa- 
tur fur das digitale Zertifikat gemaG Anspruch 1 oder 
2, das an einen Empfanger des digitalen Zertifikats 
gesendet wurde, wobei das Verfahren folgende 
Schritte umfasst: 

Erhalten eines offentlichen Schlussels der Dritt- 
partei-Zertifikat-Befugnisstelle, der einem priva- 
ten Schlussel entspricht, der durch die Zertifi- 
kat-Befugnisstelle verwendet wird, urn die digi- 
tale Signatur zu erzeugen; 
SchlieGen jeglicher offener kryptographischer 
Ordner in dem digitalen Zertifikat (30); 
Berechnen eines kryptographischen Hash des 
digitalen Zertifikats, wobei alle kryptographi- 
schen Ordner geschlossen sind; und 
Verifizieren der digitalen Signatur fur das digita- 
le Zertifikat mit dem offentlichen Schlussel und 
dem berechneten kryptographischen Hash des 
digitalen Zertifikats. 

8. Das Verfahren gemaG einem der Anspruche 3 bis 
7, bei dem der Schritt des SchlieGens eines krypto- 
graphischen Ordners X folgende Schritte umfasst: 

rekursives SchlieGen aller verschachtelten Ord- 
ner in dem Ordner X; 

Berechnen des kryptographischen Hash des In- 
halts des Ordners X; 

Ersetzen des Inhalts des Ordners X durch den 
berechneten kryptographischen Hash des In- 
halts des Ordners x; und 

Angeben, in dem digitalen zertifikat, dass der 
Ordner X geschlossen ist. 



Revendications 

1. Systeme pour permettre a plusieurs destinataires 
d'un certificat numerique structure d'autoriser un su- 
jet du certificat numerique structure, comprenant : 

un certificat numerique structure (30) ayant une 
premiere zone type d'informations d'autorisa- 
tion (37) en rapport avec un premier destinatai- 
re, une seconde zone type d'informations 
d'autorisation (50) en rapport avec un second 
destinataire, un premier dossier cryptographi- 
que (42) contenant la seconde zone type d'in- 
formations d'autorisation (50), etun second dos- 
sier cryptographique (38-44) contenant la pre- 
miere zone type d'informations d'autorisation, 
les premiere et seconde zones type d'informa- 
tions d'autorisation pouvant chacune etre lue 
lorsque ledit dossier cryptographique respectif 
contenant ladite zone respective d'informations 
est dans un etat ouvert, mais ne pouvant etre 
lue lorsque ledit dossier cryptographique res- 
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pectif est dans un etat ferme ; 
des moyens pour fermer un dossier cryptogra- 
phique comprenant des moyens pour remplacer 
son contenu par les informations parasites cryp- 
tographiques calculees de son contenu ; et 5 
caracterise en ce qu'il comprend 

une signature numerique d'une tiers auto- 
rite de certification etablissant le certificat 
numerique structure, dans laquelle lasigna- 10 
ture numerique certifie le certificat numeri- 
que, quel que soit I'etat des premier et se- 
cond dossiers cryptograph iques. 

2. Systeme selon larevendication 1 , dans lequel lecer- is 
tificat numerique comprend en outre un ou plusieurs 
parmi : 

une pluralite de zones et/ou dossiers imbrique 

(e) s al'interieurd'un des premier et second dos- 20 

siers cryptograph iques (46-54) ou des deux ; 

un nom de sujet ; et/ou ; 

une cle publique associee au sujet. 

3. Procede pour assurer la confidentiality des informa- 25 
tions d'autorisation dans un certificat numerique (30) 
partage par plusieurs destinataires, le procede com- 
prenant les etapes consistant a : 

fournir un certificat numerique comprenant au 30 
moins une premiere zone type d'informations 
d'autorisation (36) en rapport avec un premier 
destinataire et au moins une seconde zone type 
d'informations d'autorisation (38-54) en rapport 
avec un second destinataire ; 35 
fournir un premier dossier cryptographique (42) 
dans le certificat numerique, dans lequel le pre- 
mier dossier cryptographique contient I'au 
moins une seconde zone type d'informations 
d'autorisation (46-54) en rapport avec le second 40 
destinataire, I'au moins une seconde zone type 
pouvant etre lue lorsque ledit premier dossier 
cryptographique est dans un etat ouvert, mais 
ne pouvant etre lue lorsque ledit premier dossier 
cryptographique est dans un etat ferme ; 45 
fournir un second dossier cryptographique 
(38-44) dans le certificat numerique, dans lequel 
le second dossier cryptographique contient I'au 
moins une premiere zone type d'informations 
d'autorisation (36) en rapport avec le premier 50 
destinataire, I'au moins une premiere zone type 
pouvant etre lue lorsque ledit second dossier 
cryptographique est dans un etat ouvert, mais 
ne pouvant etre lue lorsque ledit second dossier 
cryptographique respectif est dans un etat 55 
ferme ; 

etablir le certificat numerique chez une tiers 
autorite de certification ; 



generer une signature numerique basee sur des 
informations parasites cryptograph iques calcu- 
lees du certificat numerique ; 
envoyer a un sujet la signature numerique et le 
certificat numerique avec les premier et second 
dossiers cryptograph iques ouverts ; 
fermer le premier dossier cryptographique au ni- 
veau du sujet, evitant ainsi I'acces en lecture a 
I'au moins une seconde zone type du certificat 
numerique ; 

delivrer, du sujet au premier destinataire, la si- 
gnature numerique et le certificat numerique 
ayantle premier dossier cryptographique ferme, 
dans lequel I'au moins une premiere zone type 
d'informations d'autorisation (37) peut etre lue 
par le premier destinataire, et I'au moins une 
seconde zone type d'informations d'autorisation 
(36) ne peut pas etre lue par le premier 
destinataire ; 

verifier I'authenticite du certificat numerique (30) 
par le premier destinataire ; et 
dans lequel I'etape consistant a fermer un dos- 
sier cryptographique X comprend I'etape con- 
sistant a remplacer le contenu du dossier X par 
les informations parasites cryptographiques cal- 
culees du contenu du dossier X. 

4. Procede selon la revendication 3, dans lequel I'etape 
consistant a verifier I'authenticite du certificat nume- 
rique comprend I'obtention d'une cle publique 
aupres de la tiers autorite de certification, la ferme- 
ture de tout dossier cryptographique ouvert dans le 
certificat numerique recu, le calcul d'informations pa- 
rasites cryptographiques du certificat numerique re- 
cu avec tous les dossiers fermes, et la verification 
de la signature numerique du certificat numerique 
avec la cle publique et les informations parasites 
cryptographiques calculees du certificat numerique 
regu. 

5. Procede de signature du certificat numerique selon 
la revendication 1 ou 2, comprenant les etapes con- 
sistant a : 

fermer tous les dossiers cryptographiques dans 
le certificat numerique ; calculer des informa- 
tions parasites cryptographiques du certificat 
numerique ; et calculer une signature numeri- 
que avec les informations parasites cryptogra- 
phiques calculees du certificat numerique et une 
cle privee de la tiers autorite de certification. 

6. Procede de delivrance du certificat numerique selon 
la revendication 1 ou 2, depuis un sujet du certificat 
numerique a un destinataire du certificat numerique, 
le procede comprenant les etapes consistant a : 

transmettre une signature numerique depuis la 
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tiers autorite de certification au sujet du 
certificat ; 

transmettre le certificat numerique ayant tous 
les dossiers cryptographiques ouverts depuis 
I'autorite de certification au sujet du certificat ; 5 
fermer un ou plusieurs dossiers cryptographi- 
ques du certificat numerique n'ayant pas les in- 
formations d'autorisation en rapport avec le 
destinataire ; et 

transmettre le certificat numerique ayant un ou 10 
plusieurs dossiers cryptographiques fermes et 
la signature numerique depuis le sujet du certi- 
ficat numerique au destinataire. 

Procede de verification d'une signature numerique is 
pour le certificat numerique de la revendication 1 ou 
2, envoyee a un destinataire du certificat numerique, 
le procede comprenant les etapes consistant a : 

obtenir une cle publique de la tiers autorite de 20 
certification correspondant a une cle privee uti- 
lisee par I'autorite de certification pour generer 
la signature numerique ; 

fermer tout dossier cryptographique ouvert dans 
le certificat numerique (30) ; 25 
calculer des informations parasites cryptogra- 
phiques du certificat numerique avec tous les 
dossiers cryptographiques fermee ; et 
verifier la signature numerique du certificat nu- 
merique avec la cle publique et les informations 30 
parasites cryptographiques calculees du certifi- 
cat numerique. 

Procede selon Tune quelconque des revendications 
3 a 7, dans lequel I'etape de fermeture d'un dossier 35 
cryptographique X comprend les etapes consistant 
a : 

fermer de maniere recurrente tous les dossiers 
imbriques dans le dossier X ; 40 
calculer les informations parasites cryptographi- 
ques du contenu du dossier X ; 
remplacer le contenu du dossier X par les infor- 
mations parasites cryptographiques calculees 
du contenu du dossier X ; et 45 
indiquerdans le certificat numerique que le dos- 
sier X est ferme. 
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